Subject: Minutes of June 22 DLSW SIG meeting

From: "Marcia Peters (8-444-4380)" <[email-masked]>
Date: Fri, 25 Jun 93 19:16:19 EDT

____________________________________________________________________

                 APPN Implementers' Workshop
         Research Triangle Park, North Carolina, USA
                      June 22, 1993
____________________________________________________________________

                         Minutes
               Data Link Switching (DLSW) SIG

Attendance:  About 70+

Notetaker's  caveat:  These  notes  represent my  best  effort to  report
accurately, but I can only write  so fast!  I take responsibility for any
mistakes in transcription or inaccurate paraphrases; all corrections will
be gratefully accepted.

                       Marcia Peters, IBM (mpeters @ ralvm6.vnet.ibm.com)

                              * * * * * *

Lee Rafalow, IBM (temporary acting SIG  chair) (LR):  This group's focus
     is to develop an industry  standard, that vendors can implement, as
     quickly as possible.   Let's use a consensus model,  keep our focus
     on our common interests, and try to reach good decisions swiftly.

Q:  How do you define consensus:

LR:  Based  on  commitment  to  a   common  objective,  you  keep  minor
     objections to  yourself, express  only major objections.   It's the
     chair's responsibility to "read" the consensus.

Michael Zadakian, Cisco  (MZ):  IBM and Cisco met over  lunch and agreed
     the following.   The purpose  is an  interoperability spec,  in the
     most timely manner,  using a consensus model, that  all vendors can
     implement.  We should (1) define how  the group can operate and (2)
     Select a chair  thru a nomination process with a  vote per company.
     The  nominees should  state how  they  would lead,  how they  would
     achieve consensus, and then we select one.

LR:  I want to clarify.  We did not  meet with cisco in order to come to
     agreement, and we did not reach any agreement.

Wayne Clark, Cisco (WC):  In other words there was no backroom politics.
     IBM met  with Cisco  because Cisco had  expressed the  most violent
     objection to the proposed process.

David Miller, IBM (DM):  (showing proposed agenda with start-stop times)
    - Agenda
    - Charter
    - Flow Control
    - Type 2.1
    - Capabilities Exchange
    - General technical discussion
There's not a lot of time for the amount the group wants to do; we could
have an evening meeting if everybody wants that.

All:  No, the baseball game is scheduled for tonight (consensus)

DM:  (showing  matrix  of  functions   and  companies  with  counts  and
     explaining how the  agenda topics were selected).   (Going thru the
     topics with the highest interest counts). 1.  Flow control 2.  MIB.
     I thought the MIB would be in  the other (SNA SNMP MIB) session but
     it's not, so we had someone bring foils on the MIB.  IBM's DLSW MIB
     is published  and available  via anonymous ftp.  3.  A  tie between
     Ethernet, Capabilities Exchange,  and ...  I thought  we could omit
     Ethernet since  IBM has ethernet  in the  field and we  expected we
     would update the RFC to show what our product is doing.

Richard  Livingston, Cisco  (RL):  Is  the 6611  the base  for the  RFC?
     Cisco does not want to base the RFC on the 6611.

Tom Danninger, IBM (TD):  Let me paraphrase  what I think you said.  Did
     you say  "It sounds  like IBM  is dictating  the agenda,  and Cisco
     objects to that"?

RL:  Yes

TD:  Yes, we'll add that to the RFC becaause we implemented that.

LR (acting  chair):  I  get  the  impression we  have  the order  wrong.
     Should we be  discussing this SIG's charter first?   Skip this, and
     go to the charter?

All:  OK (consensus)

TD:  (showing foil).  This is my interpretation of the lunch meeting <at
     the April/93  AIW> that kicked off  this SIG.  This SIG  is part of
     the AIW.

WC:  That wasn't stated at that lunch.

TD:  ...

WC:  We  said we'd  use the  AIW as  a reason  to meet.   We didn't  say
     anything  about  AIW  rules.   We  just  learned  about  the  rules
     yesterday.  Was I in left field?  What did you others hear? <at the
     4/93 lunch meeting>

LR:  Let Tom  get his say, one  person at a  time.  Then you can  have a
     turn to speak uninterrupted.

TD:  It doesn't  have to be,  it's only  my interpretation of  the lunch
     meeting.  The  key is the  scope of work.   I thought we  agreed to
     start from the RFC <1434> as  the base, and add missing pieces.  If
     things  come up  we can  consider modifying  what's in  the RFC  or
     shipped.  I want to start from the RFC as a base.  Our output would
     be a document we're all comfortable  with, to submit to the IETF as
     a draft standard.  Then additional work  at the IETF would be done.
     This body <the AIW SIG> would be done in 6 months.  I nominate Gene
     Cox <IBM>  as SIG  chair.  The  importance for  IBM is  that things
     added are  technically right, his  own technical knowledge  of DLSW
     qualifies him.

Robin Leyland, consultant  (RL):  The RFC, or the  6611?  If something's
     implemented in the 6611 and not  documented, how do we know what it
     is?

TD:  That question  was brought up there.   It's our intent to  keep the
     RFC up to  date with the product.   We didn't stop our  work on the
     DLSW when  we published the  informational RFC.   We want to  be as
     open  as  possible.  My  guys  are  here  to  tell you  what  we're
     thinking.   This  is where  we  are,  others out  there  understand
     routers better than we do.

WC:  At that  lunch, did the  other people  understand it would  only be
     part of the AIW, following the rules of the AIW?

Bill,  Proteon (B):   There was  no  mention of  AIW rules  at the  last
     meeting.  The AIW  was convenient.  We should figure  out our goal,
     then how  to organize to meet  that goal.  The industry's  best and
     finest, need sharing on all sides, then you get an interoperability
     standard.  How we organize is irrelevant to me.

Shannon Nix, Netlink (SN):  The AIW was solely a convenience.  I did not
     think the charter would be electronic or at the next meeting.

Larry Schamburg,  CrossComm (LS):   I agree with  Shannon.  IETF  had no
     interest in  DLSW, so we would  use the internet, meet  at the AIW.
     We did not know that the AIW had rules, a charter, etc.

LR:  We had some ideas, but didn't know what our procedures would be.
I'm frustrated with this meeting's focus on process, not substance.
The consensus model can prevent politics.

LS:  I have  no philosophical objection with  the RFC as the  base, with
     one caveat.  If  it has flaws from a usability  standpoint, we need
     to solve that.  I cannot ship a product that's hard to use.

TD:  Our product  is shipped.  We're  willing to discuss things,  not to
     dictate  to the  group.  It's  out there.   We have  to be  able to
     migrate.  Our intent  is NOT to impement  the BEST interoperability
     standard for SNA.  For example, somebody proposed changing the DLSW
     header format.   We're not  interested in that.   IBM won't  do it.
     We're  not  dictating.  It's  a  natural  outgrowth of  that  table
     conversation.  DLSW  and other things  shipped.  A reason  to start
     from the DLSW as a base for the standard.

MZ:  This is  the cart  before the  horse.  We  should choose  the chair
     next.   We should  nominate people,  choose, then  work within  the
     group towards a common charter.  We could be here for hours and not
     get any work done.

LR:  We're 25-30 minutes into the meeting.

Louise Herndon Wells, consultant (LW):  At  the last AIW, it sounds like
     a basic disagreement on the purpose and goal of the group.  If it's
     not resolved, the charter and the process won't work.  The question
     is (1)  Does DLSW belong to  IBM, controlled by IBM  with input and
     suggestions or  (2) We  developed DLSW,  we open it,  give it  to a
     public  forum, the  group owns  it, there's  a secretariat  to help
     communications, control of the document  by body members.  How come
     IBM is changing the spec if it belongs to this group?

LR:  I  heard differently  from Tom  Danninger.  He  said he  thought we
     <IBM> would provide  the DLSw spec and expertise,  move it forward,
     fill in  the holes.   If it's  broken, we'd  entertain discussions.
     The group has to decide if Tom's RFC is the base?

LW:  No, the non-IBM  contingent here feels differently.   It's an issue
     of  control.  IBM  said  DLSW  as a  standard.   IBM  said an  open
     standard, owned by the world.  People  can do with it as they wish.
     Rules made by this body.  You can choose to implement or not.  They
     feel it's a standard owned by the world and changed by this SIG.

MZ:  I agree.

Alan Bartky, Sync Research (AB):  I agree.

All:  (consensus) We agree.

AB:  I propose we disassociate from the AIW.

B:  IBM  thinks it's  an IBM  standard, the  others think  it's an  open
     standard.

Jim Cobban, Bell Northern  Research (JC):  I agree.  If  IBM cannot live
     within consensus, the industry will leave the AIW and set up <their
     own  SIG>  under  the  IETF.   It's less  convenient  for  us,  and
     undesirable to IBM.  IBM would lose influence and control.

TD:  I agree  with the characterization.  We  submitted an informational
     RFC.  Cisco proposed  we make  it a standard,  using the  AIW.  Any
     forum  is OK  with me.   As  to the  issue of  losing control,  IBM
     doesn't want  to CONTROL DLSW.   Our sunk investment is  what we've
     shipped.  We continued development.

LR:  Do you <the group> care about this debate?

All:  <consensus> We care about the debate.

LR:  OK.

LW:  Is it  a basic disagreement  on goals?  If  not, there's no  way to
     proceed.  If IBM is interested in DLSW being a standard, IBM should
     release the apron strings.

LR:  There are two manifestations of control,  (1) the SIG chair and (2)
     using the RFC as a base.  Is it the second one that's key?

All:  No.

LR:  Is it the chair issue?

All:  No.

LW:  It's the document, who owns it, who has the authority to change it?

TD:  Is the IETF the issue?

All:  No.

LR:  Is it the use of the RFC number <1434>?

LW:  No, it's the document, who defines what goes in it?

All:  The group, us.  (consensus)

TD:  Will the 6611 be updated?  Yes fine, each company has a decision to
     make, when  and where to  implement the  new standard.  We  have no
     intent to run the group.  Our intent  is to make a standard, and go
     implement it.  Changes can have an impact on every product.  All of
     us have to decide what to do.

MZ:  But  your  foil is  inconsistent.   "Subject  to  AIW rules"  --  I
     disagree.   "Scope of  work" --  not based  on the  implementation,
     based on the document <RFC 1434>.  It's a technical discussion.

All:  (Agreement - consensus)

LW:  IBM is adding new features.

TD:  When I  said that, I  meant it as a  gesture of openness.   Now, we
     haven't done the first minute of technical work, this group has the
     right to update the document.

LW:  Starting from RFC 1434.

TD:  Yes.  There are  only minute differences from  the current release.
     Ethernet was added, only minor changes.

LW:  Then there's a consensus, DLSW is owned by the world and managed by
     this forum.

TD:  As a consensus.

MZ:  The AIW rules are shifting ground.

Bill Northrup, Cayman (BN):  Start from what's printed.

Gene Cox, IBM (GC):  I'm the only  person who really knows what's in the
     document and  the differences.   IBM's not trying  to be  sneaky or
     keep  one  step  ahead.   Ethernet   support  did  not  change  the
     switch-to-switch  protocol.   First,  our   intent  was  simply  to
     document what we  did.  The real spec  is the .C and  the .H files.
     The RFC was a little inaccurate.

WC:  No.

GC:  And second,  it's in the  field.  We found little  flaws, corrected
     some protocols  and state machines.   It needed to be  done anyway.
     Some of you already noticed these  and sent me e-mail.  People will
     agree to these updates.  Shall I present them to this body first?

LR:  OK, I see a consensus.

John Palumbo:  It's crucial that you present them first.

All:  OK.  (consensus)

LW:  The issue of leadership is open.

LR:  What it means?

LW:  Start from the posted RFC, IBM  will submit its proposed changes to
     this body.

LR:  The chair?

LW:  Contention.   I heard  open, owned  by the  world, managed  by this
     forum.  There's an issue of what umbrella group is this forum under
     and why?  I heard people say  the AIW is convenient.  I didn't hear
     them agree to IBM rules of procedure.

LR:  No nominations  yet.  Remember  consensus, I  just want  to caution
     people about  "51% makes a  decision".  I'm  happy for this  SIG to
     make its  own rules.   I encourage the  consensus model,  avoid the
     delay of  a standards group.  What  IBM offers to this  group is to
     keep priorities  and schedules in  mind <unlike a  normal standards
     body>.  We're in transition, we're asking your trust.

B:  What if  the AIW rules are  rules our company can't  abide by?  Does
     that preclude us from being part of this SIG?

LR:  It's not control, not a reporting issue.

B:  I'm not accusing IBM of wrongdoing.  I'm just suspicious.

Matt Gerlach, ACC (MG):   Consensus is OK.  Let's  disassociate from the
     AIW, agree to use consensus, and move on from here.

LR:  Do you want me to strike  the phrase "AIW-appointed chair" from the
     foil?

RL:  And strike "AIW rules"

Steve Joyce, IBM (SJ):  The  membership agreement <draft version not yet
     distributed>  mainly  is  there  to cover  what  happens  when  you
     contribute ideas, intellectual  property law.  If we  don't use the
     AIW, you will need  to hire lawyers, do a piece of  work on how you
     want to handle  the intellectual property law issues  that come up.
     The advantage that the AIW can bring to this group.

Jane Munn,  Manager  Networking  Architectures,  IBM (JM):   I  have  no
     problem with SIG being part of the AIW or not.  It may be premature
     to decide on this.  The AIW rules  aren't final, I said it would be
     a draft.  You could defer discussion  of whether this is an AIW SIG
     until later.

LR:  OK, everybody?

All:  Yes (consensus)

MZ:  I disagree.   I want to  choose today.   Getting rules in  the mail
     makes me nervous.  This group should make its own rules.

LR:  I heard Jane Munn say she's  OK with this group choosing to divorce
     itself from  the AIW.  There  are checks  and balances on  IBM.  We
     understand that if people don't like them <the rules>, they leave.

MZ:  We need to understand the ground rules.

RL:  We can defer  the decision.  I'm concerned with  the AIW membership
     agreement.

Marcia Peters, IBM  (MP):  Give us a  break.  The people at  IBM are not
     such monsters.  Why don't you give  us a chance to let this process
     work and let us demonstrate that we are ethical and trustworthy and
     serious about  being open.  Also,  remember that the press  and our
     common users will judge what we do  here.  It will make us all look
     bad if we  are unable to work  together.  I think we  can make this
     process work if we just decide to give it a try.

LR:  Let's  focus  on  our  common interests.   This  group  offers  the
     advantage (over a normal standards body)  that it will proceed at a
     business person's pace.

WC:  Did we screw up by not choosing the IETF as the forum for this work?

All:  (consensus) The IETF is the wrong place.

MZ:  That was a consensus.  It should reflect that up there on the chart.

LR:  One hour  ago, Tom  (Danninger) proposed Gene  Cox.  Are  there any
     other nominees?

John Pickens, Mayfield  Consulting (JP):   A person with  a demonstrated
     level of interest:  Wayne Clark.

Paul Gacek, Novell (PG):  Louise Wells.

LR:  OK, now I'll ask each nominee to make a short campaign statement.

GC:  OK.  I've  worked for IBM since  1980, worked on many  products and
     link level  protocols.  I'm one of  the three founders of  the data
     link switch.  I want to see it  go based on the RFC.  At this point
     only IBM folks have operational experience  with it and I believe I
     know the  most.  For the  future, the purpose  is interoperability.
     Our intent was to update the  RFC to provide information on what we
     learned  was  bad, to  save  this  group some  time.   Capabilities
     exchange  is very  important.  It's  nothing magic,  common to  our
     customer set.

Louise Wells:   I'm the former editor  of SNA Perspective.  I  think I'm
     qualified because I'm not from  any vendor.  I'm interested but not
     biased.  I'm not  caught up in the technical  details.  I'm willing
     to be chair but not editor.

LR:  Free?

LW:  Yes.

WC:  I joined  Cisco 2 1/2 years  ago.  We have  a base of 20  to 30,000
     routers already  doing DLSW-like technology.   As chair, I  want to
     visit every  router vendor  to ensure that  the matrix  <of desired
     features>  includes everything  in their  current product  line.  I
     think we  should proceed using  small groups with expertise  in the
     area to  evolve the RFC.   I would  propose one company,  one vote.
     Consensus works.

LR:  <explains process to "vote" by consensus>

MP:  There are two qualities I would  look for in the chair.  First, the
     person should be  a master of the technology.   Second, they should
     have  good  abilities to  work  with  people,  not be  abrasive  or
     inflammatory.   I respect  both Wayne  and Gene's  mastery of  this
     technology but  I'm unsure  about the  depth of  Louise's technical
     knowledge.  I'm  pretty sure  both Gene and  Louise work  well with
     people.  As for Wayne, "works and  plays well with others"?  You be
     the judge.  I recommend Gene Cox.

RL:  The person needs to know NetBIOS  and other protocols.  All of them
     could work with consensus.  Louise is less technical.

SN:  Maybe we can get some help from examining the IETF guidelines.  The
     chair should  not be a  technical contributor.  Wayne and  Gene are
     both  obvious key  technical contributors.   Both companies  have a
     vested  interest.    A  neutral   party  is  better.    Louise  has
     demonstrated her capability to achieve consensus.

MZ:  There is merit in  both arguments, technical expertise, experience,
     neutrality.  Wayne brings a sense  of balance.  IBM is the sponsor.
     It  would look  good in  the  press that  Cisco and  IBM and  other
     vendors  can all  work  together.   A Wayne  Clark  and IBM  shared
     editorship  would make  for a  good balance.   Balance and  <media>
     perception are important.

Scott Adams, Cayman Systems (SA):  I'm concerned with a technical chair.
     I don't  know what the rules  will be.  The chair  often influences
     decisions.  I agree with Shannon.  Cisco's DLSW-like technology has
     the same problem.   I would look for neutrality and  the ability to
     forge a consensus.

LR:  I  hear consensus  on  one issue  but  not on  another.   I near  a
     consensus on the  trust issue: a contender vs.  a non-contender.  I
     don't  hear   consensus  on  the   issue  of  a  technical   vs.  a
     non-technical chair.

AB:  It's  best  that   the  chair  be  technical.   I   would  add  the
     qualification that the chair be someone known in the outside world.
     The  #1 skill  is a  people-skill.  Louise  Wells is  known in  the
     industry, and represents neither IBM nor Cisco.

?:  Gene  and Wayne  will be  able to  have an  impact because  of their
     technical skill and  personal persuasiveness.  I want  a chair with
     less  ego-attachment  to  the  work product,  therefore  I  propose
     Louise.

Steve  Simon, IBM  (SS):  I  have a  comment on  the consensus  process.
     Let's  look at  the most  serious objection,  technical skill.   Is
     there  another  way  to  solve   that?   Louise  doesn't  want  the
     editorship.

LR:  Louise fits the neutrality criterion.  There are other ways to fill
     the technical gap.

All:  (consensus) Louise Wells is the DLSW SIG chair.

                            * * * * *

LW:  The issue before the group is the formation of subgroups.

AB:  No, let's  talk about  the agenda  first.  Shall  we meet  again at
     Interop?

All:  No, let's define the issues first.

JC:  Wayne's  matrix lists  the issues  but they're  abbreviated to  1-2
     words.  There's some  confusion as to what the  items actually are.
     I agree with Alan <AB>, and there  may be new issues we want to put
     on the table, possible sub work groups.  The list is unchanged from
     last April and we were asked to vote.  Some of us didn't add things
     to the matrix until the meeting vote.

LW:  OK, when's  the next meeting  of Interop?  San  Francisco? 8/26-28?
     What about Share?  The next AIW?

TD:  Meetings at  Interop and Share?   We need proposals  and subgroups,
     circulate, then decide to meet.

LW:  All three venues  are close in time.  Share, Interop,  and the next
     AIW.

AB:  I want both AIW and Interop, but drop Share.

JC:  Budget won't let me do both.

All: One  meeting, not  2. (consensus)  Show  of hands  how many  cannot
     attend:  SF (7),  Share (15), next AIW (0).  OK,  we'll meet at the
     next AIW.

LW:  The work groups can meet separately  if they want to.  Now shall we
     add more issues or split into work groups?

RL:  We already have natural subgroups, one per issue on the matrix.

AB:  We should clarify, go through the list, agree what each item means,
     and take additions to the list, then decide on the work groups.

WC:  I agree.   We had  11 at  the last  AIW, then  added 2,  but people
     didn't want to update it.  You had to have been there <at the lunch
     meeting> to understand what each item means.

LW:  OK.  I'll ask people to define each item:

FLOW CONTROL:

GC:  Currently the DLSW protocol has no way to throttle the LLC circuit.
     (Internally, we do,  based on internal queues, and  not discard any
     data.)  On a circuit basis you want to throttle based on the number
     of frames outstanding.   We could use some of  the reserved fields,
     pacing  response,  pacing  windows,  shut.  <describes  a  sort  of
     adaptive pacing>

LW:  OK, now we understand that flow control refers to.  Next,

NODE T2.1:

WC:  T2.1 is tied to  SDLC.  I think they can be  combined.  The RFC has
     SDLC for PU type 2.0  only, all secondary.  SDLC-to-SDLC represents
     a  substantial piece  of  the  SNA traffic.   Token  ring is  still
     emerging.  My  proposal is  tied to T2.1.   If DLSW  supported XID3
     negotiation, routers don't care.  The  DLSW takes too active a role
     in link station role determination.  SDLC means SDLC anywhere.

LW:  Should we combine them then?

WC:  I wanted to propose Cisco's serial tunnelling (STUN).

AB:  Downstream converters, DSAP/SSAP issues.  <Downstream refers to the
     SDLC side of an LLC-to-SDLC protocol converter.>

JP:  An alternate name for the problem is "multiple SAPs per MAC".

PG:  The problem exists  for Netware for SAA too.   It's more prevalent,
     doesn't only apply to protocol converters.

All:  (Consensus on the name.)

GC:  There's nothing  in the spec  to prohibit this.   We do it  all the
     time.  Any-to-any even-numbered SAP.   You configure which ones are
     eligible.

AB:  How CANUREACH except in the case of a test frame?

GC:  The destination SAP=0, we just do it.

AB:  It should be the same working group then.

GC:  Already  for SDLC  and token  ring.  As  for SDLC,  Wayne mentioned
     nothing  specific  about  SDLC.    The  DLSW  *is*  an  SDLC-to-LLC
     converter.  We handle it by converting it to LLC2.  Is SDLC-to-SDLC
     different?  We'll happily share what we do.

AB:  This discussion  is technical,  it should be  included in  the work
     group.

LW:  Shall we call it "connect/disconnect"?

Don Turner,  IBM  (DT):   You  can  lump  in the  TG  row,  we  can  use
     3745-to-3745 SDLC-to-SDLC.  It represents FID4 subarea TGs.

All:  We don't have much interest in it.

WC:  That's a pretty big topic.

MP:  Before we figure out how to combine the work groups, let's continue
     and understand what all the topics are first.

ETHERNET:

Choon  Lee, 3Com  (CL):  The  Ethernet concern  is to  prevent loops  as
     non-source-routing, a method to prevent loops.  Not necessarily the
     spanning tree.

TD:  We  shipped Ethernet.   I asked  the  designer to  be available  to
     present what we did.

PRIORITY AND CLASS OF SERVICE

WC:  Priority and Class  of Service are related.   They involve priority
     and  bandwidth management.   None of  the implementations  offering
     priority support interoperate.

?:  I thought COS refers only to FID4 subarea COS.

GC:  Not only FID4, it's not limited to that.

MP:  Instead of just trying to prioritize one protocol ahead of another,
     had  you  all thought  about  trying  to  achieve a  true  "blended
     prioritization"     for    multiprotocol     traffic?     Equitable
     prioritization?

RL:  Let's not take that on here.

LW:  We can consider that in context.

CAPABILITIES EXCHANGE

WC:  This means  two DLSWs  exchange information and  try to  figure out
     their levels of capabilities.

Bill Donovan, Proteon (BD):  I understood  this item to be dividing DLSW
     into a base and options, by consensus.

LW:  It is capabilities exchange, or is it base and options?

GC:  Product  schedules won't  line up,  we  need base  and options  for
     interoperability.  E.g. what set of SAPs?  Do I need NetBIOS? etc.

MP:  I urge this body to resist  the urge to fragment your architecture.
     You may have to divide into base  and options, but I urge you to do
     it  as  little   as  possible.   Too  many  options   can  lead  to
     interoperability problems too.  Remember what happened to OSI.

CONFORMANCE

GC:  This means how  to ensure interoperability.  Define a  set of tests
     or scenarios, run them, and declare it's DLSW-conformant or not.

LW:  OK, this is  a consensus.  A set of technical  specs and a proposal
     on how to handle conformance, administer it, etc.

T2.1

LW:  SDLC is combined with T2.1.

CHANNEL

PG:  Channel is an  IBM DLC like 3172 or 3174.   It means generic enough
     to support different DLCs, for example  QLLC.  Throw it in with the
     Connect/disconnect work group?  Both are technically non-issues.

TRANSMISSION GROUPS

WC:  TG  means  multilink TGs  for  SDLC.   It also  includes  multilink
     token-ring TGs, multilink mixed-media TGs.

MP:  We see HPR as being a  technology that provides a good solution for
     MLTG.  The  RTP component at the  endpoints can put packets  in the
     right order  whether they arrived  over one  or more sets  of MLTGs
     along the end-to-end path.

DIRECTORY

PG:  Directory suggestions to minimize configuration.  A large number of
     DLSWs with their own IP addresses to configure.

AB:  We can discuss this on e-mail, we don't need a work group on it.

RL:  Directory is  important, you  sometimes find  the tables  are huge,
     20-50K entries.  You have to purge, or get a directory.  Go ask for
     it, don't  broadcast CANUREACH.   You need  it for  scalability.  I
     want a standard.

LW:  A "CANUREACH" directory service.

MP:  In the future you  might also want to think about  putting HPR as a
     different transport under the data link switch.  We think there may
     be some advantages  to this and would be interested  in hearing the
     reaction of this  body.  Also, if you think it's  a good idea, we'd
     like to work  together with the best minds in  the industry to work
     out the details.

WC:  How about DLSW over APPC?  DLSW over TP4?

JP:  How about DLSW over ATM, etc?

SECURITY

CL:  You need security to limit  a pair of DLSWs, authentication, access
     control.

GC:  The 6611 has an option to do it.  We can reveal how do we it.

WC:  This should be combined with capabilities exchange.

NETWORK NODE INTEGRATION

WC:  Network node  integration means to understand  the linkages between
     the DLSW and the APPN stack, for example, connection networks.

MIB

All:  We thought the SNA SNMP MIB group is addressing the DLSW MIB.

MP:  No, I was at that meeting and they said they assume the DLSW SIG is
     handling it.

DM:  We have a DLSW MIB.  You could start from ours.

SN:  I have  an issue.  The IEFT  group working on DLC  MIBs.  We should
     start from IBM's DLSW MIB, but work toward convergence.

LW:  In other words, we want to liase with the IETF work.

All:  Yes.

                             * * * * *

By  a show  of hands,  each person  present indicated  if they  would (1)
contribute to  or (2) audit  each working  group.  The tallies  are shown
below.  Since there are enough  contributors for each working group, none
were combined, and LW solicited volunteers to coordinate each work group.

                  Contribute       Audit      Coordinator(s)
Flow Control            7             18      Shannon Nix, Netlink
Connect/Disconnect      13            12      Alan Bartky, Sync Research
                                              Wayne Clark, Cisco
Ethernet                4             10      Choon Lee, 3Com
Priority/COS            7             12      Gene Cox, IBM
Capabilities exch       10            11      Wayne Clark, Cisco
Conformance             3             6       Rick Konlon, Cisco
MIB                     7             18      Glenn Aikens, IBM

WC:  How about the convergence of APPN over DLSW and APPN over sockets?

Dennis Wind, IBM (DW):  That's not important.

TD:  Why spend time on that.

MP:  IBM volunteers to  provide mail exploders for each  work group.  If
     you want to get on a mail exploder, send an internet note to appn @
     vnet.ibm.com.

LW:  To leave  ample review time  before the next  AIW, 9/7 will  be the
     deadline for  draft documents.  Each  work group should  send their
     contributions  to  the coordinator,  who  should  put the  proposal
     together.

MP:  I  recommend that  each work  group use  e-mail to  discuss initial
     proposals,  try to  reach  consensus, bring  their joint  proposals
     forward, and if they have  difficulty agreeing bring the contending
     proposals to this  group for input.  Don't put the  whole burden on
     the coordinator to create the proposal.

                               * * * *

The DLSW SIG adjourned.